Fix bug #40459 - make all stream funcs that create object call ctor - #153

Problem
- master took #101, which pins Mago at #118 (90e8d64) and rewrites
  Sets.sharp:75 and Sets.inc:75 so a Set's changing method has a place.
- This branch pinned #129's head (bce91aa). Both sides changed the pin line.
  #129 merged as 82593a4, which did not compile, and mago-sharp #153 fixed it
  as 625c278.

Solution
- Take master's Sets.sharp and Sets.inc as they are.
- SHARP_MAGO_COMMIT pins 625c278, the merge of
  #153, which carries both #118 and #129. The bridge sources the header is
  generated from are unchanged since bce91aa, so the pin is the only line the
  generated header changes.

Zend/tests/sharp/
  Sets.sharp, Sets.inc   from master: the copied Set is held in a local before add
ext/sharp/
  sharp_unit.h           conflict: SHARP_MAGO_COMMIT is 625c278, the merge of mago-sharp #153

… runs

Problem

The "Install elan and Lean" step never installed Lean. elan-init.sh
with --default-toolchain only sets the default toolchain, so the step
took 333 ms and passed without a download. The first test that ran
lake installed Lean 4.34.1 instead, and the 20 law tests in
tests/compile.rs each started the same install in parallel.

On #153's run 38170197612 that race failed the Ubuntu nightly job.
The tests waited on elan's lock, found a half-installed toolchain
("lake: error while loading shared libraries: libInit_shared.so"),
could not remove elan's temp toolchain directory, and one could not
resolve release.lean-lang.org. CI showed 20 failing tests for one
network problem, and a rerun passed.

Solution

The step installs the toolchain from
crates/sharp-lean/lean/lean-toolchain with elan toolchain install, then
runs that toolchain's lake --version and lean --version. If any part
fails, it uninstalls the toolchain, since elan reports a half-installed
one as installed, and tries again after 15 and then 30 seconds. After
3 failed attempts the step fails with one error that names the
version, and no test runs. cd.yml's two uses of the action get the
same check.

.github/actions/setup-lean/
  action.yml   installs the pinned toolchain, checks its lake and lean
               run, and retries a failed install twice

Problem:
Master gained #153, #154 and #130. #153 makes the same `None` fix to
`check_changed_collection` that the previous merge made, so it merges cleanly.

#154 gives `get_parameter_type` the invocation target, so a plain PHP caller reads a PHP
declaration only of a method a PHP# file declares. This branch's call in
`analyze_invocation`, which fixes a PHP# method value's type arguments from its parameter's
function type, still passed six arguments.

#130 fails any test whose `.sharp` issue names a word only PHP has, `mixed` among them. This
branch prints the type a generic member erases to as PHP declares it, so an unbounded type
parameter's erased type read "PHP's `mixed`", and six erased-signature tests failed the
check. `crates/analyzer/src/expression/access/mod.rs` gained an import on both sides.

Solution:
- `analyze_invocation` passes `&invocation.target` to `get_parameter_type`, as #154's other
  callers do.
- `display_erased` prints an erased `mixed` as PHP# writes it, `Any?`, through
  `display_sharp_type`. Only `array`, `Closure` and `callable` stay PHP's, since PHP# has
  no name for them. The six tests pin "must take at least `Any?`" and "erases to `Any?`".
- `access/mod.rs` keeps both imports.

crates/analyzer/
├── src/expression/access/mod.rs                     <- conflict: both imports
├── src/invocation/analyzer.rs                       <- #154's invocation target
├── src/statement/class_like/method_signature.rs     <- display_erased names `Any?`
└── tests/sharp.rs                                   <- six erased-signature texts